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BRIEF HISTORY 


In June 1967, ECMA TC9 received a proposal for a uniform 
enveloping format for character oriented Full Duplex Data 
Link Control Procedures. This proposal was enhanced by TC9 
and submitted to ISO/TC97/SC6 in 1969. It was adopted as a 
first working paper at the November 1969 meeting of ISO/TC97/ 
SC6. 


In March 1970 ECMA TC9 received a proposal for a bit-oriented 
frame structure which was recognized to be an improvement to 
the existing proposal. The new proposal was embraced in the 

TC9 submission to ISO/TC97/SC6 in 1970. The bit-oriented frame 
structure was a feature of the working paper which emerged 

from the June 1970 meeting of ISO/TC97/SC6. ECMA TC9 confirmed 
support in their input to the 1971 meeting of ISO/TC97/SC6. In 
June 1972, ISO/TC97/SC6 produced a proposed Draft International 
Standard containing the bit-oriented frame structure and several 
other features of high-level data link control, such as the 
command and response definitions, and circulated it to member 
bodies for voting. The proposed DIS on frame structure was 
accepted and is being processed as ISO DIS 3309. 


This present Standard on HDLC Frame Structure is in line with the 
ISO DIS 3309 and is the first of a family of standards and Re- 
commended Code of Practice, which will be enhanced later by 
adding the command and response definitions and bit allocations 
as separate standards. 


Adopted by the General Assembly of ECMA on December 13, 1973. 


INTRODUCTION 


The present Standard ECMA-4O defines the frame structure which 

is to be used for bit-oriented High-Level Data Link Control 
(HDLC). It specifies the relative positions of the frame contents 
but the detailed definition of the content of each field within 
the frame will be the subject of separate standards. 


Other standards may be generated later to specify the manner in 
Which the facilities of this standard are to be used to implement 
the requirements of specific classes of system, e.g. start-stop 
and other character enveloping structures. 


1. SCOPE 


This document defines in detail the frame structure for bit- 
oriented high level data link control. It defines the relative 
positions of the various components of the basic frame and the 
bit combination for the frame delimiting sequence (Flag). The 
bit insertion/deletion mechanism which is used to achieve 
total transparency within the frame is also defined. The docu- 
ment also specifies the Frame Checking Sequence (FCS). No 
details of the encoding of the address and control field are 
included in this specification. These will be the subject of 
separate standards. 


2. BASIC FRAME STRUCTURE 
The basic frame structure shall be as follows: 


e.l1 Frames containing Data Link Supervisory Information only 


2.2 Frames containing Data 


— fe 
3.4 


3. BASIC FRAME CONTENTS | 


3.1 Flag Sequence 


All frames shall start and end with the flag sequence. 
All stations, which are attached to the data link shall 
continuously hunt for this sequence. Thus, the flag is 
used for frame synchronization. A single flag may be 
used as both the closing flag for one frame and the 
opening flag for the next frame. 


Note: The flag may also be used to fill the time between frames. More precise rules of time fill will 
be recommended in codes of practice for given types of systems, 


3.2 Address Field 


The address field shall in all cases identify the secon- 
dary, which is involved in the interchange and, hence, 
identifies the relationship between the primary and secon- 
dary. Addresses shall be defined for each specific appli- 
cation. 


Normally a single octet address shall be used and all 
256 combinations shall be available. However, by prior 
agreement the address range can be extended by reserving 
the first bit of each address octet which would then be 
set to binary zero to indicate that the following octet 
is an extension of the basic address. The format of the 
extended octet(s) shall be the same as the basic octet. 
Thus the address extension may be recursively extended. 


When extensions are used, the presence of a binary one in 
the first bit of the basic address octet signals that only 
one address octet is being used. The use of address ex- 
tension thus restricts the range of single octet addresses 
to 126. 


4.4 Control Field 
The control field is used by the primary to command the 
secondary what operation it is to perform. It is also 


used by the secondary to respond to the primary. 


In addition sequence numbers, where used, are contained 
in the control field. 


The control field may be extended by one or more octets. 
All extensions are subject to further standardization. 


4.4 Information field 


Information may be any sequence of bits. In most cases, 
it will be linked to a convenient character structure, 
e.g. octets, but, if required, it may be an unspecified 
number of bits and unrelated to a character structure. 


The maximum number of bits to be contained in the infor- 
mation field is system dependent and is not specified in 
this Standard. 


3.5 Frame checking sequence (FCS) 
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The FCS shall be a 16 bit sequence. It shall be the re- 
mainder after division (modulo 2) by the generating poly- 
nomial 


xl6 + xle + xO? * 1 


of the content of the frame, existing between, but not 
including the final bit of the opening flag and the first 
bit of the FCS excluding bits inserted for transparency. 


Methods of detecting the presence of errors are implementa- 
tion dependent and are not specified by this Standard. 


However one method may be: 


At the receiver, the serial incoming protected bits and 
the FCS when devided by the generating polynomial will 
result in a zero remainder in the absence of trans- 
mission errors. 


Note: If future applications show that a higher degree of protection is needed, the number of 
bits of the FCS shall be increased by octets. 


Transparency 


The transmitter shall examine the frame content between 

the two flag sequences including the address, control and 
FCS sequences and shall insert a ZERO bit after all se- 
quences of 5 adjacent ONE bits (including the last 5 bits 
of the FCS) to ensure that a flag sequence is not simulated. 
The receiver shall examine the frame content and shall dis- 
regard any ZERO bit which directly follows 5 adjacent 

ONE bits. 


Order of bit transmission 


Addresses, commands, responses and sequence numbers shall 
be transmitted low order bit first, (e.g. the first bit of 
the sequence number that is transmitted shall have the 
weight 2°). 


The order of transmitting bits within the information field 
is not specified by this Standard. 


The FCS shall be transmitted to the line commencing with 
the coefficient of the highest term. 


